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REMARKS 



The examiner is thanked for the performance of a thorough search. By this amendment, 
Claim 5 is canceled; Claims 1-3, 12, 13, and 18-22 are amended; and new Claims 29-30 are 
added. Hence, Claims 1-4 and 6-30 are pending in the application. The amendments to the 
claims as indicated herein do not add any new matter to this application. Furthermore, 
amendments made to the claims as indicated herein have been made to exclusively improve 
readability and clarity of the claims and not for the purpose of overcoming alleged prior art. 

Each issue raised in the Office Action mailed September 25, 2002 is addressed 
hereinafter. 

I. ISSUES RELATING TO PRIOR ART 

A. CLAIMS 1-2, 6-9, 14-16, 20-22, 24, 27-28 

Claims 1-2, 6-9, 14-16, 20-22, 24, 27-28 are rejected under 35 U.S.C. § 102(e) as being 
unpatentable over Martin U.S. Pat. No. 6,154,776 ("Martin"). The rejection is respectfully 
traversed. 

In a proper rejection under § 102(e) the cited reference must show each and every 
claimed feature in the same combination as arranged in the claim. See Lewmar Marine, Inc. v. 
Barient. Inc. . 827 F.2d 744, 747-48, 3 USPQ2d 1766, 1768 (Fed. Cir. 1987). If even a single 
element or limitation is missing from the reference, anticipation is not found. Connell v. Sears, 
Roebuck & Co. , 722 F.2d 1542, 1548, 220USPQ 193, 198 (Fed. Cir. 1983). 

A key distinction between the claims as amended and Martin is that the claims provide 
for establishing a mapping of application information for traffic flows associated with one or 
more message types that may be generated by an application, but Martin cannot differentiate 
among multiple message types that may be generated by an application. Martin responds on 
the fly to detection of a new "entity" flow in the network and creates an association to an existing 
configuration rule. See Martin, col. 3, lines 30-56. For Martin, an "entity" is a user, an 
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application, a piece of equipment, or other network entity, but Martin fails to deal with 
multiple message types that could be generated by an application. As taught by Applicants, 
one application (such as a Finance application) can generate many different kinds of messages 
(such as a Finance Transaction message or a Finance Reporting message). Each different type of 
message can map to a different QoS treatment. See Specification at pp. 19-20. Due to this basic 
distinction, Martin does not anticipate the claims. 

The Office Action states that Martin shows "receiving device information that defines 
one or more quality of service treatments that the network device may apply to data processed by 
the network device" at col. 2, lines 7-13, and col. 7, lines 19-21, 27-30. This is incorrect. The 
cited passages teach retrieving user parameters from a directory service that are used to define 
QoS factors for a particular user, including different instances of a user on the network. 
However, this is not what is claimed. The cited claim limitation refers to receiving information 
that defines the QoS capabilities of a particular device within a network that may have many 
different kinds of devices with different QoS capabilities. Martin selects QoS on a per-user basis 
and its description of QoS enforcement point 20 and router 24 do not suggest that the network 
could contain different kinds of enforcement points or routers with different QoS capabilities. 
The claim selects QoS on a per-device basis. Martin does not teach this and therefore cannot 
support a § 102(e) rejection. Withdrawal of the rejection is respectfully requested. 

The Office Action asserts that Martin teaches "based on the device information and the 
application information, determining one or more processing policies that associate the traffic 
flows with the quality of service treatments" at col. 2, lines 17-20, col. 3, lines 32-45, 65-67, col. 
4, lines 1, 29-32, 55-60, col. 7, lines 55-59, col. 8, lines 54-57, col. 9, lines 65-67, col. 10, lines 
1-2. This is incorrect. 
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Because Martin does not determine what QoS to based on the capabilities of a network 
device, Martin does not teach determining processing policies based, in part, on device 
information. Specifically, col. 2, lines 17-20 teach use of a configuration rule (not device 
information) to define QoS based on flow characteristics. Col. 3, lines 32-45 teaches use of 
bindings based on flow parameters to dynamically select a configuration rule; no device 
information is involved. Col. 3, lines 65-67 to col. 4, line 1 teach looking up a configuration rule 
based on known flow parameters. Col. 4, lines 29-32 teach applying QoS to a device, not 
selecting which QoS to use based on device information. Col. 4, lines 55-60 teaches storing the 
configuration rules in a directory. Col. 7, lines 55-59 teaches how to determine whether a flow 
represents a new instance of an entity. Col. 8, lines 54-57 defines configuration rules as actions 
applied to a flow and to whom the actions are to be applied. Col. 9, lines 65-67 to col. 10, lines 
1-2 define lookup parameters for finding a flow. 

Nothing in Martin teaches determining what QoS to use based on device-specific 
information as well as application information. Therefore, Martin cannot support a § 102(e) 
rejection. Withdrawal of the rejection is respectfully requested. 

Further, in the independent claims as amended, the device information and the 
application information both are stored in the directory. Martin uses a directory only for storing 
QoS configuration rules. Martin has no teaching of storing application information in a directory 
or in the same directory as the device information; instead, Martin identifies entities "on the fly" 
by recognizing flow packets of entities. 

For all these reasons, Claim 1 is allowable over Martin. Claim 20 and Claim 21 are 
computer-readable medium and apparatus claims, respectively, that correspond to Claim 1. 
Claim 20 and Claim 21 have been amended in the same manner as Claim 1, and therefore are 
allowable for the same reasons given above for Claim 1 . 
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Each of the other claims depends, directly or indirectly, from either Claim 1, 20, or 21, 
and therefore each of the dependent claims includes each of the features described above that 
distinguish the independent claims. Accordingly, Martin anticipates none of the dependent 
claims. Further, each of the dependent claims is patentably distinct from Martin. Selected 
examples are now discussed. 

Regarding Claim 2 and Claim 22, the Office Action asserts that all the features of the 
claims are founding Martin. Claim 2 and Claim 22 have been amended to feature storing both the 
application information and the device information in the repository . As stated above with 
respect to Claim 1, Martin uses a directory only for storing QoS configuration rules. Martin has 
no teaching of storing application information in a directory or in the same directory as the 
device information; instead, Martin identifies entities "on the fly" by recognizing flow packets of 
entities. Therefore, Claim 2 and Claim 22 feature subject matter not found in Martin, and are 
allowable over Martin. 

With respect to Claims 14, 15, and 27, the Office Action asserts: 

. . Martin discloses determining one or more processing policies 
comprises creating and storing one or more policy statements in a repository (as 
shown in the rejection of claims 1, 6, and 8) and a policy defines actions to be 
applied to a flow and also identifies to whom the actions are to be applied 
(column 8, lines 55-57, column 9, lines 49-51). Therefore, Martin implicitly 
discloses determining one or more processing policies comprises creating and 
storing one or more policy statements in a repository, wherein each policy 
statement associates a condition of one of the traffic flows, an operator, an 
operand, and an action comprising one of the quality of service treatments." 

This rationale is legally insufficient to support an anticipation rejection. First, the rejection of 
Claim 1 has been shown to be incorrect in the discussion above. "Anticipation requires the 
presence in a single prior art disclosure of all elements of a claimed invention arranged as in the 
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claim ... A prior art disclosure that 'almost' meets that standard does not 'anticipate.'" ConnelL 
supra, 722 F.2d at 1548, 220 USPQ at 198. Claims 14, 15, and 27 explicitly require a condition 
of one of the traffic flows, an operator, an operand, and an action, and it is insufficient under 
§ 102(e) to say that a reference implies something that is explicit in the claim. One of ordinary 
skill in the art would not understand the reference to contain the specific things that are claimed. 
Therefore, the rejection of Claims 14, 15, and 27 should be withdrawn. 

The rejection of Claims 16 and 28 is similarly insufficient in relying on implicit 
disclosure in Martin. 

B. CLAIMS 3-5 AND 23 

Claims 3-5 and 23 are rejected under 35 U.S.C. § 103 as allegedly unpatentable over 
Martin in view of Chapman U.S. Pat. No. 6,028,842. With respect to Claims 3 and 23, the Office 
Action contends that Chapman teaches classifying traffic flows. However, this is not what is 
claimed. 

First, Claim 3 includes all the features discussed above with respect to Claim 1, and 
therefore is distinct from Martin for the same reasons given above with respect to Claim 1. 
Further, Claim 3 recites creating and storing one or more classes that classify the traffic flows. 
As amended, the classes are associated with one of the message types, i.e., message types 
generated by an application. As detailed in the specification, the information recited in Claim 3 is 
created and stored in advance of receiving any traffic flows that actually represent a particular 
message type. 

In contrast, Chapman teaches dynamic classification after traffic has been received. The 
disclosure of Chapman with respect to classification must be taken in the context of the entirety 
of the Chapman disclosure, which is how it would be understood to one of ordinary skill in the 
art. Chapman teaches discovering the nature of the service for each traffic flow; in contrast, in 
Applicants' disclosure message types are explicitly mapped to QoS classes by an administrator. 
If one of skill in the art combined Chapman with Martin, the result would be an on-the-fly 
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system that would detect entity flows and dynamically classify them. This is not the combination 
that is claimed in Claims 3 or 23. 

Still further, Claim 3 recites "based on the device information and the classes of the 
traffic flows, determining one or more processing policies that associate the traffic flows with the 
quality of service." Chapman has no teaching of using device information, which indicates the 
capabilities of a device to apply QoS, to determine what policy should apply to a particular 
application flow. 

Regarding Claim 4, the Office Action asserts that the six "classes of traffic flow" 
described in Chapman are the same as the application code points recited in the claims. This is 
incorrect. As clarified in the specification, "ACPs identify and define one or more types of traffic 
flows or classes that are produced by an application." In Chapman, classes represent multiple 
applications that generate traffic of a similar priority or characteristic. There is no teaching about 
associating multiple different traffic flows or message types from one application with different 
QoS values. Therefore, a combination of Chapman with Martin does not reach the claimed 
invention, and Claim 4 is allowable. 

Claim 5 has been canceled solely because it appears to inadvertently present subject 
matter that substantially duplicates the subject matter of Claim 4. 

C. CLAIMS 10, 17, AND 26 

Claims 10, 17 and 26 are rejected under 35 U.S.C. § 103 as allegedly unpatentable over 
Martin in view of Chapman U.S. Pat. No. 6,028,842 and further in view of Haddock et al. U.S. 
Pat. No. 6,104,700. The rejection is respectfully traversed. 

Haddock is asserted for a teaching of DSCPs. It has none. While Haddock states that 
"traffic groups with a higher priority are preferred over those with lower priorities," this is not a 
teaching of DSCPs. The term DSCP has an industry- standard meaning, as described in IETF 
RFC 2475, a copy of which is submitted herewith in an Information Disclosure Statement. 
Haddock has no mention of DSCPs in this sense, and nothing in Haddock or RFC 2476 teaches 
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the use of DSCPs as a target for a mapping of application code points or application message 
types. 

Further, for the reasons previously given with respect to Claim 1, Claim 21, and Claims 
4-5, a combination of Martin and Chapman fail to reach the claimed invention. In Chapman, 
classes represent multiple applications that generate traffic of a similar priority or characteristic. 
There is no teaching about associating multiple different traffic flows or message types from one 
application with different QoS values. Therefore, a combination of Chapman with Martin does 
not reach the claimed invention. The addition of Haddock does not result in the complete 
combihation invention as claimed because of the deficiencies of Martin and Chapman. 

D. CLAIMS 11-13 AND 19 

Claims 11-13 and 19 have been rejected under 35 U.S.C. § 103 as allegedly unpatentable 
over Martin in view of Haddock et al. U.S. Pat. No. 6,104,700. The rejection is respectfully 
traversed. 

Claims 11-13 each depend, directly or indirectly, on Claim 1 and therefore include all the 
features described above with respect to Claim 1. Accordingly, Claims 1 1-13 are patentably 
distinct from Martin for the reasons given above for Claim 1, and any combination of Martin 
with Haddock cannot reach the complete combination that is claimed. 

Further, with respect to Claim 11, while Haddock mentions RSVP in its Background 
section, there is no teaching or suggestion to use RSVP in the manner recited in Claim 1 1 as a 
whole. A proper 103 rejection must be supported by a "factual inquiry whether to combine 
references that is thorough and searching." In re Lee , 61 USPQ2d 1430 (Fed. Cir. 2002). A 
showing of a suggestion, teaching, or motivation to combine the prior art references is an 
"essential component of an obviousness holding." In re Dembiczak , 175 F.3d 994, 999, 50 
USPQ2d 1615, 1617 (Fed. Cir. 1999). The showing must come from the references themselves 
and cannot be based on hindsight. In re Lee , supra at 1434. 

Nothing in Haddock suggests combining the use of RSVP with Martin or a system like 
Martin. Haddock merely notes the existence of RSVP and indicates that it is inadequate for his 
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application. There is no teaching that RS VP ought to be combined with Martin. Even if such a 
combination occurred, at most it would provide for on the fly sensing of new entities, selecting a 
configuration rule, and issuing RSVP reservations. It would not provide the subtle but important 
features of Claim 1 and the other independent claims that are identified above. Accordingly, 
Haddock is not properly combined with Martin and does not teach, suggest or disclose the 
complete claimed invention. 

Concerning Claims 12-13, the Office Action asserts that "Haddock discloses control over 
bandwidth allocation and traffic priority is in the hands of network managers." However, as 
amended, Claim 12 specifies that the application information is established by someone who 
manages applications, and not by the network manager. Claim 13 is made dependent on Claim 
12 and therefore includes the same feature. The point of Claims 12-13 is that different 
individuals, with different areas of expertise, enter information that is within their expertise and 
are not required to perform configuration operations beyond their expertise. As described in the 
specification, the application manager sets up mappings of application message types or code 
points to application message flows. The network manager sets up mappings of the message 
types to QoS values. As a result, QoS treatment of application flows closely matches the 
capabilities of the application and the devices in the network. 

Haddock, however, merely refers to "network managers" in a broad sense and without 
suggesting the specific features of Claims 12-13. Accordingly, Claims 12-13 are patentably 
distinct from Haddock and Martin and are believed to be allowable. 

Claim 19 recites features that are similar to features found in Claim 1, 2, 6, and 8 and has 
been amended in the same manner as such claims. Therefore, Claim 19 is allowable for the same 
reasons given above with respect to Claim 1, 2, 6, and 8. The Office Action asserts Haddock for 
a teaching of DSCPs. It has none. While Haddock states "traffic groups with a higher priority are 
preferred over those with lower priorities," this is not a teaching of DSCPs. The term DSCP has 
an industry-standard meaning. Haddock has no mention of DSCPs in this sense, and nothing in 
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Haddock or RFC 2476 teaches the use of DSCPs as a target for a mapping of application code 
points or application message types. 

Further, for the reasons previously given with respect to Claim 1, 2, 6, and 8, a 
combination of Martin and Haddock fail to reach the claimed invention. There is no teaching 
about associating multiple different traffic flows or message types from one application with 
different QoS values. Therefore, a combination of Martin with Haddock does not reach the 
claimed invention. 

E. CLAIM 18 

Claim 18 is rejected under 35 U.S.C. § 103 as allegedly unpatentable over Martin in view 
of McCloghrie et al. U.S. Pat. No. 6,286,052. The rejection is respectfully traversed. 

As amended, Claim 1 8 features issuing a QoS request using an application QoS policy 
element that is tightly coupled to the application program . In a sense, Claim 18 recites in a 
proper, broad, functional manner the general principle illustrated by FIG. 6B in which 
application QoS policy element 609 calls the "setsockopt" function of UNIX, or the GQoS 
function of Windows NT, to cause network device 620 to apply a particular QoS to a flow 
generated by application 608. In this way, application 608 can selectively apply different QoS to 
different flows for different message types. 

McCloghrie, col. 20, lines 19-40 merely suggests that operating system functions can be 
called by a specialized server and used for traffic management. McCloghrie has no suggestion 
that general purpose application program of the type disclosed by Applicants can be tightly 
coupled to an application QoS policy element that selectively applies QoS treatments to different 
flows issued by the application. Thus, in combination, McCloghrie and Martin cannot reach the 
claimed invention. 

II. CONCLUSIONS & MISCELLANEOUS 

For the reasons set forth above, it is respectfully submitted that all of the pending claims 
are now in condition for allowance. Therefore, the issuance of a formal Notice of Allowance is 
believed next in order, and that action is most earnestly solicited. 
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The Examiner is respectfully requested to contact the undersigned by telephone if it is 
believed that such contact would further the examination of the present application. Please 
charge any shortages in fees to Deposit Account No. 50-1302. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 

Dated: TO VM^lO Q^ i^l^4n^ 

Christopher J. Palermo 
Reg. No. 42,056 

1600 Willow Street 
San Jose, California 95125-5106 
Telephone No.: (408) 414-1080 
Facsimile No.: (408)414-1076 
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Washington, D.C. 20231 
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